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Reducing the Standards Track to Two Maturity Levels 
Abstract 
This document updates the Internet Engineering Task Force (IETF) 


Standards Process defined in RFC 2026. Primarily, it reduces the 
Standards Process from three Standards Track maturity levels to two. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6410. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


This document changes the Internet Standards Process defined in RFC 
2026 [1]. In recent years, the Internet Engineering Task Force 
(IETF) witnessed difficulty advancing documents through the maturity 
levels: Proposed Standard, Draft Standard, and finally Standard. 
These changes are designed to simplify the Standards Process and 
reduce impediments to standards progression while preserving the most 
important benefits of the IETF engineering approach. In addition, 
the requirement for annual review of Standards Track documents that 
have not reached the top of the maturity ladder is removed from the 
Internet Standards Process. 


Over the years, there have been many proposals for refining the 
Internet Standards Process to reduce impediments to standards 
progression. During May 2010, the Internet Engineering Steering 
Group (IESG) discussed many of these proposals. Then, a plenary 
discussion at IETF 78 in July 2010 demonstrated significant support 
for transition from a three-tier maturity ladder to one with two 
tiers. 


In the Internet Standards Process, experience with a Proposed 
Standard is expected to motivate revisions that clarify, modify, 
enhance, or remove features. However, in recent years, the vast 
majority of Standards Track documents are published as Proposed 
Standards and never advance to a higher maturity level. Very few 
specifications have advanced on the maturity ladder in the last 
decade. Changing the Internet Standards Process from three maturity 
levels to two is intended to create an environment where lessons from 
implementation and deployment experience are used to improve 
specifications. 


The primary aspect of this change is to revise the requirements for 
advancement beyond Proposed Standard. RFC 2026 [1] requires a report 
that documents interoperability between at least two implementations 
from different code bases as an interim step ("Draft Standard") 
before a specification can be advanced further to the third and final 
maturity level ("Standard") based on widespread deployment and use. 
In contrast, this document requires measuring interoperability 
through widespread deployment of multiple implementations from 
different code bases, thus condensing the two separate metrics into 
one. 


The result of this change is expected to be maturity-level 
advancement based on achieving widespread deployment of quality 
specifications. Additionally, the change will result in the 
incorporation of lessons from implementation and deployment 
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experience, and recognition that protocols are improved by removing 
complexity associated with unused features. 


In RFC 2026 [1], widespread deployment is essentially the metric used 
for advancement from Draft Standard to Standard. The use of this 
same metric for advancement beyond Proposed Standard means that there 
is no longer a useful distinction between the top two tiers of the 
maturity ladder. Thus, the maturity ladder is reduced to two tiers. 


In addition, RFC 2026 [1] requires annual review of specifications 
that have not achieved the top maturity level. This review is no 
longer required. 


2. Two Maturity Levels 


This document replaces the three-tier maturity ladder defined in RFC 


2026 [1] with a two-tier maturity ladder. Specifications become 
Internet Standards through a set of two maturity levels known as the 
"Standards Track". These maturity levels are "Proposed Standard" and 


"Internet Standard". 


A specification may be, and indeed, is likely to be, revised as it 
advances from Proposed Standard to Internet Standard. When a revised 
specification is proposed for advancement to Internet Standard, the 
IESG shall determine the scope and significance of the changes to the 
specification, and, if necessary and appropriate, modify the 
recommended action. Minor revisions and the removal of unused 
features are expected, but a significant revision may require that 
the specification accumulate more experience at Proposed Standard 
before progressing. 


2.1. The First Maturity Level: Proposed Standard 
The stated requirements for Proposed Standard are not changed; they 
remain exactly as specified in RFC 2026 [1]. No new requirements are 
introduced; no existing published requirements are relaxed. 

2.2. The Second Maturity Level: Internet Standard 
This maturity level is a merger of Draft Standard and Standard as 


specified in RFC 2026 [1]. The chosen name avoids confusion between 
"Draft Standard" and "Internet-Draft". 
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The characterization of an Internet Standard remains as described in 
RFC 2026 [1], which says: 


An Internet Standard is characterized by a high degree of 
technical maturity and by a generally held belief that the 
specified protocol or service provides significant benefit to the 
Internet community. 


The IESG, in an IETF-wide Last Call of at least four weeks, confirms 
that a document advances from Proposed Standard to Internet Standard. 
The request for reclassification is sent to the IESG along with an 
explanation of how the criteria have been met. The criteria are: 


(1) There are at least two independent interoperating implementations 
with widespread deployment and successful operational experience. 


(2) There are no errata against the specification that would cause a 
new implementation to fail to interoperate with deployed ones. 


(3) There are no unused features in the specification that greatly 
increase implementation complexity. 


(4) If the technology required to implement the specification 
requires patented or otherwise controlled technology, then the 
set of implementations must demonstrate at least two independent, 
separate and successful uses of the licensing process. 


After review and consideration of significant errata, the IESG will 
perform an IETF-wide Last Call of at least four weeks on the 


requested reclassification. If there is consensus for 
reclassification, the RFC will be reclassified without publication of 
a new RFC. 


As stated in RFC 2026 [1], in a timely fashion after the expiration 

of the Last Call period, the IESG shall make its final determination 
and notify the IETF of its decision via electronic mail to the IETF 

Announce mailing list. No changes are made to Section 6.1.2 of RFC 

2026 [1]. 


2.3. Transition to a Standards Track with Two Maturity Levels 


Any protocol or service that is currently at the Proposed Standard 
maturity level remains so. 


Any protocol or service that is currently at the Standard maturity 
level shall be immediately reclassified as an Internet Standard. 
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Any protocol or service that is currently at the abandoned Draft 
Standard maturity level will retain that classification, absent 
explicit actions. Two possible actions are available: 


(1) A Draft Standard may be reclassified as an Internet Standard as 
soon as the criteria in Section 2.2 are satisfied. 


(2) At any time after two years from the approval of this document as 
a BCP, the IESG may choose to reclassify any Draft Standard 
document as Proposed Standard. 


3. Removed Requirements 
3.1. Removal of Requirement for Annual Review 


In practice, the annual review of Proposed Standard and Draft 
Standard documents after two years (called for in RFC 2026 [1]) has 
not taken place. Lack of this review has not revealed any ill 
effects on the Internet Standards Process. As a result, the 
requirement for this review is dropped. No review cycle is imposed 
on Standards Track documents at any maturity level. 


3.2. Requirement for Interoperability Testing Reporting 


Testing for interoperability is a long tradition in the development 
of Internet protocols and remains important for reliable deployment 
of services. The IETF Standards Process no longer requires a formal 
interoperability report, recognizing that deployment and use is 
sufficient to show interoperability. 


Although no longer required by the IETF Standards Processes, RFC 5657 
[2] can be helpful to conduct interoperability testing. 


4. Security Considerations 
This document does not directly affect the security of the Internet. 
5. Acknowledgements 


A two-tier Standards Track has been proposed many times. Spencer 
Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003. 
Additional proposals were made by Scott Bradner in 2004, Brian 
Carpenter in June 2005, and Ran Atkinson in 2006. This document 
takes ideas from many of these prior proposals; it also incorporates 
ideas from the IESG discussion in May 2010, the IETF 78 plenary 
discussion in July 2010, and yet another proposal submitted by 
Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in 
November 2010. 
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